feat: add Mathpix PDF extraction - #26

Notes from review. The shape of this is fine; it's the failure paths that need work before it goes near a real PDF.

No timeouts. None of the three HTTP calls (mathpix.py:60, :80, :95) pass timeout=, so a stalled connection hangs the command indefinitely with no way to tell what's happening.

Polling treats every failure as "not ready yet" (:79-84). Any non-200 response, whether that's a bad API key, an unknown id, a server error or a conversion that failed outright, just sleeps and retries. The user waits the full five minutes and is then told the conversion "did not finish in time", which sends them looking in the wrong place. Polling GET /v3/pdf/{id} for the conversion status and raising on an error status would report the real problem in seconds.

response.json()["pdf_id"] (:64) raises a bare KeyError when Mathpix returns an error body, which reads like a bug in in2lambda rather than a rejected upload.

It can overwrite a file the user cares about. pdf_to_markdown writes <pdf stem>.md into out_dir (:68-70), and in the wizard PR out_dir is the folder of the user's chosen output file. So in2lambda wizard notes/paper.pdf -o notes/draft.md silently replaces notes/paper.md if it exists. Returning the markdown as a string, and only writing the figures, would avoid it entirely.

Failed figure downloads are skipped silently (:95-97), leaving the markdown pointing at a local file that was never written. A warning would do.

Two more, both worth a line in the docs rather than code: the PDF is uploaded to a third party, which teachers should be told about, and Mathpix has a training opt-out that we probably want set. Also, has this been run against the real service yet? The tests mock it, so what they check is our assumptions about the API rather than the API itself.